IBIS Macromodel Task Group

Meeting date: 10 September 2024

Members (asterisk for those attending):
Achronix Semiconductor:       Hansel Dsilva
Amazon:                       John Yan
ANSYS:                      * Curtis Clark
                            * Wei-hsing Huang
Aurora System:                Dian Yang
                              Raj Raghuram
Cadence Design Systems:     * Ambrish Varma
                              Jared James
Dassault Systemes:            Longfei Bai
Google:                       Hanfeng Wang
                              GaWon Kim
Intel:                      * Michael Mirmak
                            * Kinger Cai
                              Chi-te Chen
                              Liwei Zhao
                              Alaeddin Aydiner
                              Sai Zhou
Keysight Technologies:      * Fangyi Rao
                              Majid Ahadi Dolatsara
                              Stephen Slater
                              Ming Yan
                              Rui Yang
Marvell:                      Steve Parker
Mathworks (SiSoft):         * Walter Katz
                              Graham Kus
Micron Technology:            Justin Butterfield
Missouri S&T:               * Chulsoon Hwang
                            * Yifan Ding
                              Zhiping Yang
Rivos:                        Yansheng Wang
SAE ITC:                      Michael McNair
Samsung:                      Jun-Bae Kim
Siemens EDA (Mentor):       * Arpad Muranyi
                            * Randy Wolff
Signal Edge Solutions         Benjamin Dannan
Teraspeed Labs:               [Bob Ross]
Zuken USA:                    Lance Wang

The meeting was led by Arpad Muranyi.  Curtis Clark took the minutes.

--------------------------------------------------------------------------------
Opens:

- Arpad noted that he had sent an email to ATM and the Editorial task group
  about a possible discrepancy in the language related to thresholds and zero-
  crossings in the context of PAM4.  He said it might be a simple editorial
  correction, and we could discuss it here in ATM or in Editorial.

-------------
Review of ARs:

- None.

--------------------------
Call for patent disclosure:

- None.

-------------------------
Review of Meeting Minutes:

Arpad asked for any comments or corrections to the minutes of the August 27th
meeting.  Michael moved to approve the minutes.  Ambrish seconded the motion.
There were no objections.

--------------
New Discussion:

BIRD220.1 update:
Yifan reviewed a presentation, IBIS SPICE Validation, which contained the
results of her case study using the SPICE circuit Arpad had provided.  Yifan
noted that the PSIJ Sensitivity BIRD had been developed considering a driver
design with a common pre-driver feeding both the pullup and pulldown devices.
In that scenario, the PSIJ had proven to be independent of load, and a single
keyword for PSIJ for each edge (rising/falling) was sufficient.

Arpad's circuit contained different pre-drivers for the pullup and pulldown
stages.  Yifan set up tests into 3 different load conditions: 50 Ohms to Vcc,
50 Ohms to Vss, and 20pf to Vss.  She showed results for cases with noise on
the predriver rail, noise on the final stage rail, and both.  The results showed
that while the pre-driver PSIJ values for each of the individual pre-driver
stages were still independent of load, the PSIJ of the final output varied
considerably with load.

Yifan investigated whether an equivalent representation using a single common
predriver could be found.  She studied whether a single modified input to the
final driver could reproduce the behavior seen under all load conditions, but
she found that this was not possible.  She presented results for a case study
of the 50 Ohm to Vss case.  The input to the final stage was shifted over a
range that produced an output variation matching the PSIJ that had been seen
under that load condition.  However, when this same set of shifted inputs was
provided to the final stage under the other two load conditions, the results
did not match the PSIJ that had been observed.

Yifan concluded that the current algorithm for BIRD220.1 might be limited to
cases with a common pre-driver for the pullup and pulldown stages.  Arpad asked
whether we could handle this by introducing two keywords, one for the pullup and
one for the pulldown.  Chulsoon said he thought this would be difficult.  Randy
said he thought the case with independent pre-drivers was much more common than
the simpler case with a single pre-driver.

Arpad asked what the plan for this BIRD is, given the new information?  Chulsoon
said they were seeking feedback.  At present they don't have a workaround for
the more general case.  Arpad said that stating the limitation is one option.
He said the current proposal would work for open drain or open source devices,
which only have one transistor.  It would also work for a buffer with pullup and
pulldown transistors and a common pre-driver.  The only issue is a buffer with
pullup and pulldown transistors and independent pre-driver stages.  Arpad asked
how a model maker would know what's inside their buffer and whether it was
suitable for BIRD220.1?  He said some model makers may not be familiar with the
content of the transistor level model from which they extract the data for the
IBIS model, i.e., they treat it like a black box.  Yifan suggested that a
technique similar to what she had done to test Arpad's model might work.  If the
model maker determined that a single set of shifted input waveforms could
duplicate the PSIJ results under all load conditions, then BIRD220.1 could be
used with that device.

Arpad reviewed a set of curves he had generated previously with the same SPICE
model.  The curves showed the rising and falling transitions when driving a
resistive load into various V_fixture values.  He noted that the curves for
values of V_fixture between Vss and Vdd showed a plateau in the middle of the
transition at the V_fixture value.  He said this was the period when neither
transistor was active, as the transistor turning off is shut off before the
other transistor is turned on.  He said this is done to eliminate crowbar
currents during the transition.  Arpad wondered whether this type of test,
for example, looking for a plateau in the transition when driving into Vdd/2,
could be used to determine whether the proposed PSIJ parameter could be applied
to the model for this device.

Chulsoon and Yifan agreed to draft an update to the BIRD that includes a
description of the limitation.  Yifan agreed to send the presentation to the ATM
list.

Ts4file and [Ramp]:
Michael reported that the Editorial task group had discussed his draft BUG
report related to the ibischk parser checking [Ramp] vs. I-V data, even when the
AMI parameter Ts4file exists in the model.  He said it was clear from that
discussion that we needed a strategic discussion in ATM before any potential
parser behavior change could be defined.

Michael reviewed new proposed language in his BIRD draft.  He had incorporated
changes suggested at the previous meeting.  He noted that he had applied the
same "first order estimate" language, used to describe the purpose of [Ramp] in
the presence of [External Model], to the case of Ts4file.  He had also added
language stating that [Ramp] data should be consistent with the behavior when
the Ts4file circuit is hooked up to an identical test load.  Michael asked
whether EDA vendors thought [Ramp] was still necessary if Ts4file is provided.

Arpad offered his high-level summary of the issues.  He said no matter what
types of data are provided (legacy I-V and V-t, Ts4file, [External Model]),
ideally the [Ramp] data should be consistent with them, and they should be
consistent with each other.  He said we tend to neglect the [External Model] in
this discussion, but we should be sure we are consistent there too, particularly
since the Ts4file section currently mentions that [External Model] should be
used if the model maker wants to provide the same electrical behavior in a non-
AMI context.

Michael agreed, but he said he avoided addressing the [External Model] issue
because of parser complications.  He said if we say [Ramp] data "should" match
then the language is fuzzy and vague.  However, if we say it "must" match, then
we're obliged to have the parser check.  He noted that Walter had said solving
for a Ts4file circuit hooked up to 50 Ohms to ground was fairly easy, and the
parser could implement that "simulation."  However, if we say that the [Ramp]
consistency check is also required for [External Model], then processing that
"simulation" would be very hard for the parser.  Arpad agreed that cross-
checking [Ramp] vs. [External Model] was beyond the scope of the parser.

Michael said one possible way around this issue would be to push the consistency
checking to the EDA tool itself.  If a tool supported [External Model], for
example, it could check for consistency with [Ramp].  He said we might be able
to define a flow or API to specify that behavior, but it would not be trivial to
do.  In addition, until we defined that behavior, we might still have models
being issued with [Ramp] data that doesn't agree with Ts4file or
[External Model] data.

Arpad returned to Michael's question about [Ramp] data.  He said that IBIS 7.2
says the [Ramp] keyword is required ("must"), but it does not say that it "must"
match the other data.  Michael agreed.  He said [Ramp] is required, but the
specification only mentions cross-checking with respect to the I-V tables.  We
don't even mention [Rising Waveform] and [Falling Waveform].  The parser,
however, is more specific.  When used with the -caution flag, the parser
checks the dV portion of the [Ramp] data against what would be expected with
the static I/V tables hooked to the same load.  Michael said the IBIS Cookbook
is not the law in this case, but it goes into detail about the checking.

Walter agreed with Arpad that [Ramp] should still be required.  He said he
thought Michael's proposed "should be consistent" language was fine.  He said
[Ramp] is well defined and the dV/dt is a measurement.  He said the tool should
be allowed to assume that the [Ramp] data is correct.  He said Ts4file is
another way to model the device.  The [Ramp] measurement should agree with the
Ts4file data.  If they don't agree, then it's up to the user to decide which to
use and whether the model is worth using.

Ambrish agreed with Walter that the "should" language was sufficient.  In an
ideal world it would be nice if the parser could cross check everything, but
since Ts4file and [External Model] are somewhat outside of the normal scope of
the IBIS parser, the checking for consistency was not required.

Michael agreed, but he said the natural question that arises is what to do with
with the parser checks.  Right now, the parser (with -caution flag) will force
the model maker to provide [Ramp] data that agrees with the I-V table data (if
I-V data is provided).  In a Ts4file scenario, what do we do about a tool that
suffers adverse simulation effects if the [Ramp] data provided is inconsistent
with the Ts4file?  Ambrish said that when Ts4file was introduced, the intent was
that nothing else in the .ibs file would be used in the simulation.  The Ts4file
was a sufficient representation of the entire buffer.  If that was the intent
then, why are we discussing it again?

Michael said this went back to his original question about Ts4file and the
parser checks.  If Ts4file is intended to replace all the legacy analog IBIS
information, then everything else can be ignored, and we should just have the
parser stop checking all the other stuff.  However, since consensus in the
group is that [Ramp] should still be provided, how do we make sure the value
is reasonable and doesn't cause simulation issues?

Arpad said his primary concern wasn't that [Ramp] exactly match.  He said as
long as [Ramp] in the neighborhood it's okay.  He said the problem for Michael
is that the parser is checking [Ramp] vs. I-V curves when Ts4file is used.
Randy said that if Ts4file is replacing everything analog in the .ibs file, then
the parser could stop checking all kinds of analog keywords (e.g., monotonicity
of I-V data, etc.).  Ambrish noted that I-V data is not even required in an IBIS
[Model].  Randy said the parser currently checks all sorts of things, even when
Ts4file exists in the .ami file.

Ambrish said we may not have properly cross checked all the existing language
when new keywords and AMI parameters were added, but the Ts4file case should
be analogous to [External Model], which is supposed to replace the legacy analog
data.  Walter said we have to be careful about what we mean by "replace".  He
said for Ts4file we should instead say "use instead of".  That is, if a model
uses Ts4file, then in some simulations the Ts4file data should be used and in
other simulations the legacy IBIS analog data could be used.  Any given
simulation should use one or the other.  Walter also suggested that Michael's
new language stating that Ts4file is used for "initial channel characterization"
should be changed to simply "channel characterization".  He said the channel
characterization is the initial step of an AMI analysis.

Michael said that if both the Ts4file and the legacy analog information can
exist in the same model, then they both need to be valid.  Ambrish noted that
[Ramp] had been the original keyword, and when waveform data was introduced
[Ramp] was still required for tools that didn't support rising and falling
waveforms.  Arpad and Ambrish said that the purpose of [Ramp] and been redefined
to providing "first order" bandwidth information in the [External Model] case.
Ambrish said that, keeping this evolution in mind, we should review the
specification again and make sure the relationship between Ts4file and [Ramp] is
consistent with previous precedent.

- Walter: Motion to adjourn.
- Curtis: Second.
- Arpad: Thank you all for joining.

New ARs:

Yifan:  Send her "IBIS SPICE validation" presentation slides to ATM.

Yifan:  Prepare a new draft of BIRD220.1 with a description of the limitation of
        the algorithm.

Michael:  Send out an updated Ts4file proposal containing changes discussed in
          the meeting.

-------------
Next meeting: 17 September 2024 12:00pm PT
-------------

IBIS Interconnect SPICE Wish List:

1) Simulator directives
